Deriving fault architectures from defect history

As software systems evolve over a series of releases, it becomes important to know which components are stable compared to components that show repeated need for corrective maintenance. The latter is a sign of code decay. Code decay can be due to the deterioration of a single component. In this case it manifests itself in repeated and increasing problems that are local to the component. A second type of code decay is due to repeated problems that become increasingly difficult to fix and are related to interactions between components. That is, components are repeatedly fault-prone in their relationships with each other. The latter requires repairs in multiple components and is a sign of problems with the software architecture of the system. Software architecture problems are by far more costly to fix and thus it is very desirable to identify potential architectural problems early and to track them across multiple releases. To do this, we adapt a reverse architecting technique to defect reports of a series of releases. Fault relationships among system components are identified based on whether they are involved in the same defect report, and for how many defect reports this occurs. There are degrees of fault-coupling between components depending on how often these components are involved in a defect fix. After these fault-coupling relationships between components are extracted, they are abstracted to the subsystem level. We also identify a measure for fault cohesion (i.e. fault-proneness of components locally.) The resulting fault architecture figures show for each release what its most fault-prone relationships are. Comparing across releases makes it possible to see whether some relationships between components are repeatedly fault-prone, indicating an underlying systemic architecture problem. We illustrate our technique on a large commercial system consisting of over 800 KLOC of C, C++, and microcode.